home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 14 / CU Amiga Magazine's Super CD-ROM 14 (1997)(EMAP Images)(GB)(Track 1 of 3)[!][issue 1997-09].iso / CUCD / Programming / AMOS / AMOSList0597 / AMOSLIST / text0309.txt < prev    next >
Encoding:
Text File  |  1997-06-01  |  3.0 KB  |  93 lines
  1. On 26-May-97, --==MURRAY==-- wrote:
  2.  
  3. >>>Say for a horizontal scrolling system. Using offset to move along
  4. >>>and then every 16 or 32 pixels, it copys the screen across to the
  5. >>>left, draws the side, resets the screen offset and continues.
  6.  
  7. >>Okay, you realize this is never going to be very fast. Transfering
  8. >>such a huge block of ChipRAM via the blitter is a BIG bottleneck...
  9.  
  10. >How would you recommend then?
  11. >(It's actually 8 way scroller I'm talking about, just the example
  12. >was horizontal)
  13.  
  14.    
  15.    Create a more optimized-design so you are never actually
  16.    directly "scrolling" the screen.
  17.  
  18.    I can give you a general idea, but I need the specific
  19.    requirements of the scroll/game.
  20.  
  21.    Now, do you need to update the (scrolling) background scenery,
  22.    like blowing up buildings and such?
  23.  
  24.    Finally, can you work with the OCS/ECS Dual-Playfield mode?
  25.  
  26.  
  27.  
  28.    Alright, for now, here is the general design:
  29.  
  30.    1. Create your screen (buffered)with a scroll "buffer", the size of
  31.       one tile, on each side.
  32.  
  33.       For a 320x240 visible game-area with 16hx16v tiles, you would
  34.       open a 352hx272v screen.
  35.  
  36.    2. Initialize the stage-display
  37.  
  38.       As usual, build your first section of the stage by drawing the
  39.       tiles into your 352hx272v screen and display the 320hx240v
  40.       area in the center: Screen Offset ScreenNumber,16,16
  41.  
  42.    So far, so good. 
  43.  
  44.    3. Now, for the fun!!  The actual scrolling design is:
  45.  
  46.       we can hardware-scroll one tile (16 pixels) in any direction.
  47.  
  48.       While we are hardware-scrolling, we need to rebuild the bitmap
  49.       with the entire screen "shifted" by one tile-block.
  50.  
  51.       Once the hardware-scroll is exhausted, we swap the new
  52.       "shifted" stage into view and reset the Offset to x=16,y=16.
  53.  
  54.  
  55.    In this example, you would need to draw (22h x 15v) 330 tiles in
  56.    order to rebuild the screen, BUT you actually have 16 frames to
  57.    do this in.
  58.    An obvious method would be to draw one row of tiles in each
  59.    frame, now you are only drawing 22 tiles at any one time.
  60.  
  61.    Note that by increasing the size of the scroll-border, you can
  62.    stretch out the hardware scroll and reduce the number of tiles  
  63.    blitted in one frame...
  64.  
  65.  
  66.    Obviously, this is MUCH easier to use in Dual-playfield displays
  67.    as you don't have to worry about your bobs getting in the way!!
  68.  
  69.    Hmmm... how to do it in AMOS without Dual-Playfield!! It has no
  70.    direct support for bitmaps which makes the whole process a bit
  71.    trickier. Working within AMOS you would need to actually create
  72.    a second Game-screen.
  73.  
  74.  
  75.    HA!HA! Well, are you confused now?
  76.  
  77.    I really need to do some work on the shooter, but I will have a go
  78.    (time permitting) at implementing a non Dual-playfield version of
  79.    this scroll-design.
  80.  
  81.    You may want to wait and try this method in the AGA extension.
  82.    We're using AGA Dual-playfield in our BLITZ game for the scroll
  83.    benefits as well as the fact that AGA DP has 16+16 colors!!
  84.  
  85.  
  86.  
  87.                               Take care,
  88.  
  89.                               Garfield
  90.  
  91.  
  92.  
  93.